home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940019.txt < prev    next >
Internet Message Format  |  1994-11-13  |  6KB
  1. Date: Sun, 23 Jan 94 04:30:06 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #19
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sun, 23 Jan 94       Volume 94 : Issue   19
  11.  
  12. Today's Topics:
  13.                    JNOS, TNOS, and other DOS'isms 
  14.                          NO TNOS sample files
  15.      Reverse IP lookup, and domain name mapping. (help) (2 msgs)
  16.                      TCP MSS and TCP WIN settings
  17.  
  18. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  19. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  20. Problems you can't solve otherwise to brian@ucsd.edu.
  21.  
  22. Archives of past issues of the TCP-Group Digest are available
  23. (by FTP only) from UCSD.Edu in directory "mailarchives".
  24.  
  25. We trust that readers are intelligent enough to realize that all text
  26. herein consists of personal comments and does not represent the official
  27. policies or positions of any party.  Your mileage may vary.  So there.
  28. ----------------------------------------------------------------------
  29.  
  30. Date: Sat, 22 Jan 1994 09:53:59 -0500
  31. From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
  32. Subject: JNOS, TNOS, and other DOS'isms 
  33. To: tcp-group@ucsd.edu
  34.  
  35. In your message of Fri, 21 Jan 1994 20:56:00 GMT, you write:
  36. +---------------
  37. |people were not arguing over it. No one knows what the future is going to look
  38. |like, but I personally hope it looks a lot more like Unix or OS/2 than Windows.
  39. |  My own view is that it is up to the people who write the source code.
  40. +------------->8
  41.  
  42. Only in part; but as always, the final decision is up to the people who *use* 
  43. the code.  There are several choices for Unix "NOS" (in quotes because I 
  44. include kernel-based solutions that don't involve dedticated NOS executables) 
  45. already; OS/2 NOS development seems to be lagging, and I'm not sure what there 
  46. is (native) for MS-Windows, if anything; but, should those environments have 
  47. NOS versions available, which one will be "the" future NOS environment will 
  48. depend on how many people choose which environments.
  49.  
  50. (Nor is this specific to NOS.  The same considerations apply to the choice of 
  51. environment for any other application, whether it be amateur radio networking 
  52. or databases.)
  53.  
  54. What the developers do is enable that decision to be made; they don't make the 
  55. decision for you.
  56.  
  57. ++Brandon
  58. --
  59. Brandon S. Allbery       kf8nh@kf8nh.ampr.org         bsa@kf8nh.wariat.org
  60. "MSDOS didn't get as bad as it is overnight -- it took over ten years
  61. of careful development."  ---dmeggins@aix1.uottawa.ca
  62.  
  63. ------------------------------
  64.  
  65. Date: Sun, 23 Jan 94 01:50:03 PST
  66. From: algedi!gateway (gateway)
  67. Subject: NO TNOS sample files
  68. To: tcp-group@ucsd.edu
  69.  
  70. Caveat: I have not found any sample autoexec or cfg files for TNOS at ucsd or lantz's
  71. location.  Anyone not familiar with creating such will be stuck for a while.
  72.  
  73. -Mike
  74.  
  75. ------------------------------
  76.  
  77. Date: Sun, 23 Jan 94 17:49:40 -0400
  78. From: "Andy Silliker" <ve1dln@jupiter.sun.csd.unb.ca>
  79. Subject: Reverse IP lookup, and domain name mapping. (help)
  80. To: nos-bbs@hydra.carleton.ca
  81.  
  82. Hello all.
  83.  
  84. I am experience a few problems here. I use a SLIP server to gain access to 
  85. the internet. I have my own IP. (156.34.110.113) I have a problem. My
  86. service provider (nbnet.nb.ca) does not have my IP mapped to a domain name
  87. (ve1dln.nbnet.nb.ca, i'd assume), hence I cannot access certain telnet and 
  88. ftp sites, nor what was my alternate NNTP server. 
  89.  
  90. Now for the questions. Can someone explain Reverse domain name resolution 
  91. to me? And, is there a way I can work around this with NOS? My service 
  92. provider does not seem to have it in their heart to soon map my IP, and I
  93. am rather perturbed not being able to access some of these sites.
  94.  
  95. Any help would be appreciated.
  96.  
  97. Andy.
  98. ve1dln@nbnet.nb.ca
  99.  
  100. ------------------------------
  101.  
  102. Date: Sat, 22 Jan 1994 16:58:56 -0800
  103. From: Phil Karn <karn@qualcomm.com>
  104. Subject: Reverse IP lookup, and domain name mapping. (help)
  105. To: ve1dln@jupiter.sun.csd.unb.ca
  106.  
  107. Andy,
  108.  
  109. You're basically stuck. The only quick workaround is to log into
  110. another machine on the Internet that does have a reverse DNS entry and
  111. issue your FTPs from there.
  112.  
  113. The policy of denying anonymous FTP access to sites that don't have
  114. reverse DNS entries has irritated me for some time. Not only because
  115. of the egregious violation of the Internet Principle (be conservative
  116. in what you send, liberal in what you accept) but also because of the
  117. hostility to personal privacy that seems to underly this policy.
  118.  
  119. A few years ago there was a big outcry against the government
  120. (specifically the FBI) attempting to find out what books people
  121. checked out from libraries. The librarians quite properly resisted
  122. this intrusion into their patrons' personal privacy. I'm appalled by
  123. the opposite trend by those who run anonymous FTP sites -- the closest
  124. Internet equivalent to public libraries. Keeping statistics on how
  125. often a file is accessed in order to better manage the space allocated
  126. to anonymous FTP is one thing, but keeping detailed logs of who
  127. obtains what file is unnecessary once a server has been debugged.
  128.  
  129. I've had a few ideas on how one might use NOS to build anonymity into
  130. IP along the lines of the existing "cypherpunk" anonymous
  131. remailers. This would let you pull files from an anonymous FTP site
  132. without having to use your real IP address. And of course, the IP
  133. address that the FTP site sees could have an inverse DNS entry.
  134.  
  135. Phil
  136.  
  137. ------------------------------
  138.  
  139. Date: Sat, 22 Jan 1994 20:57:31 -0800
  140. From: Phil Karn <karn@qualcomm.com>
  141. Subject: TCP MSS and TCP WIN settings
  142. To: kf5mg@kf5mg.ampr.org
  143.  
  144. Jack,
  145.  
  146. I don't know about the variants of my code, but I know this stuff is in 
  147. my version. Check tcpin.c, function proc_syn. Note the call to ip_mtu
  148. with the remote IP address as argument. This function, defined in iproute.c,
  149. returns the MTU of the interface that will be used to reach the specified
  150. remote IP address.
  151.  
  152. Phil
  153.  
  154. ------------------------------
  155.  
  156. End of TCP-Group Digest V94 #19
  157. ******************************
  158.